Monitoring web application behavior from a browser using a document object model

ABSTRACT

Methods and systems to test of web browser enabled applications are disclosed. In one embodiment, a browser application can allow a user to perform test and analysis processes on a candidate web browser enabled application. The test enabled browser can use special functions and facilities that are built into the test enabled browser. One implementation of the invention pertains to functional testing, and another implementation of the invention pertains to pertains to site analysis.

CROSS-REFERENCE TO OTHER APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/211,305, filed Mar. 4, 2014, and entitled “METHOD AND SYSTEM FORTESTING WEBSITES,” which is hereby incorporated by reference herein, andwhich in turn is a divisional of U.S. patent application Ser. No.13/764,635, filed Feb. 11, 2013, and entitled “METHOD AND SYSTEM FORTESTING WEBSITES” (now U.S. Pat. No. 8,683,447), which is herebyincorporated by reference herein, and which in turn is a divisional ofU.S. patent application Ser. No. 12/247,753, filed Oct. 8, 2008, andentitled “METHOD AND SYSTEM FOR TESTING WEBSITES” (now U.S. Pat. No.8,392,890), which is hereby incorporated by reference herein, and whichin turn claims priority benefit of U.S. Provisional Patent ApplicationNo. 60/980,068, filed Oct. 15, 2007, and entitled “METHOD SYSTEM ANDSYSTEM FOR TESTING WEBSITES,” which is hereby incorporated by referenceherein.

This application also references (i) U.S. Pat. No. 7,231,606 which ishereby incorporated by reference herein; and (ii) U.S. patentapplication Ser. No. 11/758,624, filed Jun. 5, 2007, and entitled“METHOD SYSTEM AND SYSTEM FOR TESTING WEBSITES”, now U.S. Pat. No.7,757,175, which is hereby incorporated by reference herein.

COPYRIGHT NOTICE

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the U.S. Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND OF THE INVENTION Field of the Invention

The present invention relates to software testing and, moreparticularly, to automated analysis and testing of websites.

Description of the Related Art

Websites are complex collections of information intended to be viewedand used and interacted with by sending information from a WebSiteserver over the Internet to users who work with this information from aninternet browser (client program) that typically runs on a computingdevice, such as a personal computer (PC). A common browser is theInternet Explorer (IE) browser that runs on Microsoft Windows. However,the invention can also equally apply to non-IE browsers.

Testing and analysis of Web Applications and WebSites is needed forvarious reasons:

-   -   1. To confirm content and proper operation and proper content        (functional testing and validation).    -   2. To determine delivered performance of a web application        server (timing and tuning).    -   3. To analyze capacity of the WebSite server by imposing        realistic loads (server loading).    -   4. To identify properties and characteristics of collections of        pages (site analysis).

There are several alternative methods that can be used to obtaininformation about how a WebSite behaves. These alternative methods areas follows: (1) Intercept of the Windows event loop, which means thatthe program has to process every keyboard activity and/or mouse activityat the primitive level of where it interacts with the operating system(OS). (2) Intercept the HTTP protocol sequence by building a wrapper ora proxy around a browser instances, thereby extracting the sequence ofinteractions between the browser and the WebSite server. (3) Captureinformation within the browser by building a free-standing browser withtest capabilities.

Thus there is a need for improved approaches to testing websites.

SUMMARY

The invention generally relates to testing of web browser enabledapplications. In one embodiment, a browser application can allow a userto perform test and analysis processes on a candidate web browserenabled application. The test enabled browser can use special functionsand facilities that are built into the test enabled browser. Oneimplementation of the invention pertains to functional testing, andanother implementation of the invention pertains to pertains to siteanalysis.

The invention can be implemented in numerous ways, including as amethod, system, device, or apparatus (including graphical user interfaceand computer readable medium). Several embodiments of the invention arediscussed below. These embodiments can be used separately or in anycombination.

Other aspects and advantages of the invention will become apparent fromthe following detailed description taken in conjunction with theaccompanying drawings which illustrate, by way of example, theprinciples of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will be readily understood by the following detaileddescription in conjunction with the accompanying drawings, wherein likereference numerals designate like structural elements, and in which:

FIG. 1 is a block diagram of a test-enabled browser according to oneembodiment.

FIG. 2 is a flow diagram of test-enabled browser processing according toone embodiment.

FIG. 3 is a block diagram of browser interfaces according to oneembodiment.

FIG. 4 is a section of representative DOM internal content according toone embodiment.

FIG. 5 is a block diagram of a website test system according to oneembodiment.

DETAILED DESCRIPTION OF THE INVENTION

The invention generally relates to testing of web browser enabledapplications. In one embodiment, a browser application can allow a userto perform test and analysis processes on a candidate web browserenabled application. The test enabled browser can use special functionsand facilities that are built into the test enabled browser. Oneimplementation of the invention pertains to functional testing, andanother implementation of the invention pertains to pertains to siteanalysis.

A test enabled web browser can provide many advantages in terms ofcontrol of the test process, ability to measure at a fine level ofdetail, to manipulate and validate the contents of WebSite pages as theyare rendered, and/or to extract linking and other information fromWebSite pages in their fully rendered form.

A system, method or apparatus (including graphical user interface andcomputer readable medium) is disclosed for testing and analyzingWebSites via a test enabled web browser. In one embodiment, a user cancontrol the test enabled web browser via a set of pull-down menus,thereby choosing between alternative testing and analysis functionalcapabilities. In one embodiment, the invention is thus a test enabledweb browser that has all of the functionality of the parallel IEtechnology and which has all required test functionality built in andeasily accessible by a WebSite analyst.

In the WebSite analysis process the test enabled web browser can act asa constrained search engine which examines pages in the candidateWebsite according to a set of inclusionary and exclusionary rules.During the automated browsing each browsed pages is analyzed for a rangeof quality attributes such as performance, content, structure andorganization. Results of these analyses can be made available in avariety of ways for use by analysts.

The general result of systematic use of the invention on WebSites canyield improved content quality, demonstrated WebSite server behaviorfrom an end-user perspective, and better serviceability for e-businessenterprises.

According to one embodiment, the techniques disclosed herein can usetechniques described in detail in U.S. Pat. No. 7,231,606, entitled“Method and System for Testing Websites,” which is hereby incorporatedherein by reference. Terminology, concepts, organization, and technicalaspects of that Patent are used herein.

A. Browser Operation

FIG. 1 is a block diagram of a test-enabled browser 100 according to oneembodiment. The test-enabled browser 100 is designed to provideautomated analysis and testing of websites. The test-enabled browser 100operates on a computing device (not shown). The test-enabled browser 100makes use of Internet Explorer (IE) base library 102. In this regard,the test-enabled browser 100, in effect, emulates a browser but furtherprovides the capability to perform the automated analysis and testing ofwebsites. The test-enabled browser 100 receives triggers 104 from anoperating system. These triggers (or event triggers) are, for example, amouse click, a mouse drag, a return, text entry, etc. Based on thesetriggers 104, the test-enabled browser 100 operates to perform theautomated analysis and testing of websites. In doing so, thetest-enabled browser 100 can produce a log file 106 or can interact witha database of information 108.

B. Browser Signaling

FIG. 2 is a flow diagram of test-enabled browser processing 200according to one embodiment. The test-enabled browsing processing 200is, for example, suitable for performance by the test-enabled browser100 illustrated in FIG. 1.

A test-enabled browser processing 200 initially begins with a decision202 that determines whether a trigger has been received. When thedecision 202 determines that a trigger for the test-enabled browser hasnot yet been received, then the test-enabled browser processing 200awaits such a trigger. Once the decision 202 determines that a triggerhas been received for the test-enabled browser, test-based processing isperformed 204. Here, the test-based processing is the processing neededto carry out the particular type of testing being performed on adetermined website. Following the performance of the test-basedprocessing, browser-based processing is performed 206. Here, thebrowser-based processing is processing typically performed by a browserapplication (network browser). Here, the browser-based processing, inone implementation, can be provided using the code resources stored forexample in the IE-based functional library 102 illustrated in FIG. 1.Following the operation 206, the test-enabled browser processing 200returns to repeat the decision 202 and subsequent blocks so thatsubsequently received triggers can be similarly processed.

C. Browser Internal Operation

FIG. 3 is a block diagram of browser interfaces according to oneembodiment of the invention. As FIG. 3 shows, the internal structure ofa typical browser involves a variety of standard components thatinteract to produce the browsing experience.

In the case of the subject invention, one of which embodiments is a testenabled browser referred to as a product called “eValid”, thesecomponents can operate in unison to provide a realistic browsingexperience, but also to provide such auxiliary functions as:

-   -   1. Making a recording of user actions as sensed internally at        300 and 301 to produce a test script;    -   2. Acting to dynamically modify candidate recording actions        based on actual actions taken by the browser based on its        interaction with the web application under test, called Adaptive        Playback 302;    -   3. Playback of recorded scripts 303 based on the content of the        recorded script;    -   4. Modification of playback based on actual behavior of web        application under test as it interacts with the test enabled        browser; and    -   5. Sensing and modification of the underlying Document Object        Model (DOM) at 304 for special purposes of the test process as        commanded by the user (see below).

In addition to internal page-specific capabilities, the invention alsoincludes

-   -   1. An external interface 305 to allow the collection of data        about the test,    -   2. A browser desktop interface 306 to permit the browser to        communication to other processes in the computer,    -   3. Access 307 to the HTTP/S protocol that is used to communicate        to/from the web application server,    -   4. Local file access 308 to keep records of the entire test        activity.

The internal state 309 of the browser is maintained because the browseruses standard browsing components, in the form of DLLs 310 that areavailable with any browser.

D. Browser DOM Structure

The relationship between the browsed page and its internal DocumentObject Model (DOM) is critical to understanding how the inventionachieves its effects. In a web page there is a collection of DOMelements that describe each part of the page, some visible to the userand some meaningful only to the browser. DOM elements are available inthe browser after the web page is rendered. Individual element arenumbered from the top of the page (element zero) to the bottom of thepage with integers. Each DOM element may have a collection of associatedattributes (sometimes also called properties) which are dependent on thecontent of the page.

FIG. 4 is a section of representative DOM internal content according toone embodiment. In FIG. 4, item 400 shows an index value of an element,reflected here in the representative implementation as the value of the“sourceIndex” attribute “51”. The HTML (HyperText Markup Language) tagnames are identified with their own naturally occurring names. Forexample, 401 shows the value of element 51's attribute “tagName” is“TD”, and for in 402 the same element has an attributed named“innerText” with the value “A Google approach to email.” As shown in thediagram the actual text appearing in the web page rendering is given at403 as “<B>A Google approach to email</B>. The position of thisparticular element (element number 51) in the tree of other elements isshown in the tree structure 405.

The embodiment of the invention includes the ability to read, scan,analyze, modify, adjust, and change the particular values of anyattribute of any element in the current DOM. This capability is requiredfor such capabilities as test playback synchronization on DOM values, onvalidation of particular attributes of page elements, and/or onuser-prompted modification of DOM elements for specific purposes. Theseare typical uses of the ability within the invention to read, analyze,and modify the DOM, but no limit to the use of this capability isimplied.

E. Structure of Representative Implementation

FIG. 5 is a block diagram of a website test system according to oneembodiment. One or more embodiments of the invention appear in a testenabled browser product, whose structure and organization are shown inFIG. 5. This diagram identifies the relationships between the externallyviewed product features:

-   -   1. Recorded scripts 500 are created by and read and executed        (played back) but the test enabled browser 501, which can be        edited 502 and converted into load test logs 503.    -   2. Playback operation involves the creation of various event        logs 504 and their subsets, such as the Performance Log 505, the        Message Log 506, and the Timing log 507.    -   3. When multiple copies 508 of the test enabled browser are        running then a special 509 LoadTest log is used to capture        details of individual playbacks.    -   4. Scans of websites using the spider/search function create        reports 510 the relate to whole-site analysis.

F. Internal Embodiments Based on DOM Operations

Additional applications of the invention's ability to analyze the DOMstructure of a browser page include the following. For example, one ormore embodiments can provide Detailed Page Analysis For Properties.

1. Client Perspective

One aspect of test enabled web browsers is that they can scan “over thewire” and “from the client perspective”—a significant technicaladvantage. Access to the DOM for analytic purposes is assured becausethe test enabled web browser uses standard browser components, amongwhich is an interface to the DOM for each web page that is browsed. Acharacteristic of the implementation of this feature is that theresulting analysis and/or spidering of the web page is dependent on howthe page actually exists at the time it is served to the test enabledweb browser, and does not include or exclude any details or effects thatare pertinent to the structure, organization, layout, and content of theweb page. The operation of the search and scan activity creates adatabase of information about individual pages and their interactionsand dependencies, such that the database can be used for later offlineanalysis.

2. Link Extraction

The test-enabled web browser can see in the pages in complete detail,extract anything, and use that information in website comparisonactivities. The analysis of properties is assured because of thearchitecture of the test enabled web browser. All of this information isavailable because the test enabled web browser uses standard browsercomponents, among which is an interface to the DOM for each page that isbrowsed. A characteristic of the implementation of this feature is thatthat the information that is collected and stored in a database isavailable using standard browsing components and standard DOM models,such as are typically employed in available general purpose web browsersof several kinds and types.

3. DOM Spidering

More selective inclusion and exclusion of links in the work-to-be-donelist/tree. This is key to a successful and useful scan, being able todecide based on page properties, mainly the URL but also on otherinternal criteria, whether to add it to the work list. If you did not dothis you would have to scan everything you find, and you may not wantthat. User control is important. The criteria for inclusion andexclusion are inclusive of any property of the page, its componentelements, its DOM properties, and its links to other pages. All of thisinformation is available because, in one embodiment, the test enabledweb browser uses standard browser components, among which is aninterface to the DOM for each page that is browsed. A characteristic ofthe implementation of this is that the origin of the search processdescribed above can be determined by the user, so that the search can bemade of one or more websites or sub-websites, as specified by a startingor “root” URL and as constrained according to the claimed limits andconstraints, so that data can be collected on full websites orsub-websites according to the wishes and expectations of the user.

4. Cross-Page Dependency Lists

Page to page dependency capture based on the dynamic links within thecurrent page (web page) can be performed. The page to page dependencytree can be kept internally in a linked list of parent-childdependencies. Those pages at/below an established root can be considereda subwebsite.

A characteristic of the implementation of this feature is that theinterface between the analysis function and the database function is onethat can use standard database interface components, such thatalternative database systems can be used to contain the information thatis captured without any loss of information or content.

Below various embodiments of a test enabled browser are discussed. Inparticular, embodiments of the invention can provide, support or use oneor more of: AJAX Synchronization; Page Face Motion Playback; PageElement/Event Stimulation; Page Element Validation; Page Get/PutOperation; Page Navigation Header Manipulation; DOM-Based AdaptivePlayback; Programming Language Interface; URL Sequence Capture; and/orPage Analysis and Structure Extraction.

A. AJAX Synchronization

AJAX (Asynchronous JavaScript and XML), is a technology for rich-clientbrowser-based applications. This approach is sweeping the technicalcommunity. Based on advanced use of JavaScript, AJAX representscompetition to the less flexible capabilities available in such productsas Adobe/FLEX.

For functional testing the challenge imposed by AJAX is to synchronizeplayback of test scripts in an environment which is inherentlyasynchronous. Advanced test script playback synchronization, virtually anecessity for AJAX implementations, can be implemented in the subjectinvention with DOM-based methods. Locking in this capability addscapability to synchronize inherently asynchronous processes to reproduceuser input.

A characteristic of the implementation of this feature is that the testenabled web browser has multi-threaded access to the DOM of the currentpage, or has the capability of simultaneous access of the DOM in concertwith other browsing activities, so that one or more synchronizationactivities or processes can proceed in parallel with other asynchronousactivities that may be operating within the browser.

1. Representative Implementation

This command can allow for synchronization of playback based on theappearance of a particular value for a specified DOM element on a page.The command can also support Adaptive Playback to provide forintelligent behavior even when the page changes slightly.

The following commands are indicative of the kinds of actions that canbe included in the invention, but they are not exclusive. The examplesbelow are present in the representative implementation but similarcommands or variants of them would be present in other implementations.The sense and behavior of the commands is independent of theimplementation.

COMMAND SYNTAX EXPLANATION SyncOnSelectedObjProperty wid Synchronizesplayback based on idx DOM_name DOM_value specified DOM name and value“frame_path” combination. SyncOnSelectedObjProperty wid Synchronizesplayback based on idx“ id_value” DOM_name specified DOM name and valueon DOM_value “frame_path” an element with specified ID tag in thespecified element. SyncOnSelectedObjProperty wid Synchronizes playbackbased on idx“ id_name” “id_value” specified DOM name and value onDOM_name DOM_value an element with specified ID tag “frame_path” andvalue in the specified element. SyncNotOnSelectedObjProperty widSynchronizes when a specified idx DOM_name DOM_value DOM name and valueare NOT “frame_path” present in the specified element.SyncNotOnSelectedObjProperty Synchronizes when a specified wid idx“id_value” DOM_name DOM name and value are NOT DOM_value“ frame_path”present in the specified element which must have the specified ID tagname. SyncNotOnSelectedObjProperty Synchronizes when a specified wid idx“id_name” “id_value” DOM name and value are NOT DOM_name DOM_valuepresent in the specified element “frame_path” which must have thespecified ID tag name and value. SyncOnElementProperty Waits for a namedelement wid “name” “Value” property to have a specified value.“frame_path” Playback continues when any element's specified propertyhas the required value. This applies to any property of any elementanywhere in the DOM. SyncNotOnElementProperty wid Waits for a namedelement “name” “Value” “frame_path” property and value to NOT befound--anywhere in the DOM. Playback continues the first time that anyelement has the required property not equal to the required value.

2. Suggested Usages

Here is a typical instance of use of this command to synchronize on thevalue of the DOM object feature in window 0 at DOM index 254 namedProcessing_State to take on the value DONE:

-   -   SyncOnSelectedObjProperty 0 254 Processing_State DONE “” Pauses        playback until ID Processing_State=DONE.    -   SyncOnSelectedObjProperty 0 254 IDvalue Processing_State DONE “”        Pauses playback until ID Processing_State=DONE, and then        confirms there is a element named IDname.    -   SyncOnSelectedObjProperty 0 254 IDname IDvalue Processing_State        DONE “” Pauses playback until ID Processing_State=DONE, and then        also confirms that the property named IDname=IDvalue.    -   SyncOnSelectedObjPropertyNOT 0 254 Processing_State DONE “”        Continues playback if ID Processing_State=DONE is not true.    -   SyncOnSelectedObjPropertyNOT 0 254 IDname Processing_State DONE        “” Continues playback if ID Processing_State=DONE is not true        AND that element does NOT have a property named IDname.    -   SyncOnSelectedObjPropertyNOT 0 254 IDname IDvalue        Processing_State DONE “” Continues playback if ID        Processing_State=DONE is not true AND that element does NOT have        a property named IDname=IDvalue (but any other value causes the        playback to pause).    -   SyncOnElementProperty 0 Processing_State DONE “” Waits until        SOME element anywhere in the DOM has a property name        Processing_State with value=DONE.    -   SyncNotOnElementProperty 0 Processing_State DONE “” Waits until        NO element anywhere in the DOM has a property name        Processing_State with value=DONE.

3. Intended Application

The main intended purpose of this command is to provide auxiliaryplayback synchronization for pages that do not completely adhere tostandard synchronization methods that are provided by a test enabledbrowser. Among many types of implementation, AJAX-built pages tend tohave this characteristic.

To apply the command successfully you may need to study the internalstructure of the page that you are trying to synchronize on, find the IDof the element whose value you are searching to match, and then adjustthe test enabled browser's behavior using the SyncOnDOM command to waitfor that element to take on the required value.

4. Escapement Mode Synchronization Method

In practice it probably may be required to operate a chain of thesecommands in escapement mode, according to one of these patterns:

-   -   (+) [(−) (+)]{circumflex over ( )}n    -   (−) [(+) (−)]{circumflex over ( )}n    -   (+) is a wait command waiting for a specified positive event, or        a timeout.    -   (−) is a wait command waiting for a specified negative event, or        a timeout.    -   [ ]{circumflex over ( )}n indicates there may be multiple such        instances in a sequence.

B. Page Face Motion Playback

In both AJAX and other web application technologies, there is a need tobe able to create scripts that are language and page-detail independent.This need arises because of the use of pages where the content isgenerated dynamically.

This kind of work is done in the representative implementation with aseries of commands that find, move, manipulate, and manage the locationof an index value—without having to be concerned with the specifics ofwhat that value is but what it points to, including pointing to thingsthat are a fixed relative location away from a searchable property(property value).

A characteristic of the implementation of this feature is that the testenabled web browser has multi-threaded access to the DOM of the currentpage, even when the browser is performing other functions in parallelwith the operation of the DOM inspection and analysis process. Theadaptive playback feature implemented in the representativeimplementation does not apply to these operations.

1. Representative Implementation

The basic idea of these commands is to make it possible to have playbacksequences that move around within the current page and perform certainactions based on what is found there.

These commands give the tester the ability to create test scripts that“navigate” within the current page, possibly in a series of separatesteps, to page objects and elements by their visible or DOM name, oreven by DOM property name and value, without reference to specific DOMindexes. Because no specific DOM index needs to be identified thesetests will be insensitive to inconsequential page changes.

2. Background Information About Web Pages

The context for these commands is based on the organization of the webpage in terms of its DOM. Every web page has a DOM that is organized asa collection of elements, each of which has a set of named properties.Individual properties associated with an element on the page may take ona specific value.

Many page elements have a variety of pre-defined properties, which arethere and have meaning due to certain standards, but some pages have“custom properties” that can take on values as well. Each DOM elementhas [by default] a property named “sourceIndex” [note that propertynames are case sensitive], whose values uniquely number the elements, 0,1, 2, . . . in order in the DOM tree and in rough order of layout of thepage on the screen. The assumption here is that the “searching” beingdone is based on the delivered pages having this variable structure, butwithin which there is enough constancy of structure to make thehigh-level process of exploiting the order of elements feasible.

3. Working Assumptions About These Special Commands

Here are background assumptions that apply this type of command:

-   -   There is only one sourceIndex known to the test enabled web        browser at any time.    -   The initial value of the sourceIndex is always set to zero.    -   The value of the sourceIndex persists between pages.    -   Commands that use this [internally stored] sourceIndex value        always refer to the current page.    -   The test enabled browser does not modify the sourceIndex except        by action of the commands below.    -   Because motion on the page is from the perspective of the view,        a search DOWN toward the bottom of the page means increasing        index numbers, whereas a search UP toward the top of the page        means decreasing index numbers.    -   If that's not confusing enough, maybe this will help (or not):        if you go all the way UP on a page, you're at sourceIndex 0.

4. A Note About Perspective

The relative orientation of the web page being manipulated is importantto understand:

-   -   UP: This means “up” on the page as seen by the viewer, i.e.        toward the top of the page, and this means decreasing index        numbers.    -   DOWN: This means “down” on the page as seen by the viewer, i.e.        toward the bottom of the page, and this means increasing index        numbers.

5. Command Descriptions in Representative Implementation

DOM Element Manipulation/Motion Commands Working Assumptions About TheseCommands: There is only one sourceIndex known to eValid at any time. ThesourceIndex is always an integer. The initial value of the sourceIndexis always set to zero. The value of the sourceIndex persists betweenpages. Commands that use this [internally stored] sourceIndex valuealways refer to the current page. eValid does not modify the sourceIndexexcept by action of the commands below. Because motion on the page isfrom the perspective of the view, a search DOWN toward the bottom of thepage means increasing index numbers, whereas a search UP toward the topof the page means decreasing index numbers. COMMAND SYNTAX EXPLANATIONIndexFindElement wid {UP | DOWN} Starting from the current“property_name” [property_value] sourceIndex, this command “frame_path”moves up or down in the DOM element index number sequence until eValidreaches the next element with a property of the specified“property_name” [or until it reaches the next element with a property ofthe specified “property_name” which has the specified “property_value”],or until eValid reaches the end [or beginning] of the page. The indexmovement is either UP (decreasing index numbers) initial index ispositive or zero. of DOWN (increasing index numbers). When a match iffound this command leaves the sourceIndex set to the index of thematching HTML element, if found. If no match is found, the sourceIndexwill remain the same. IndexFindElementEx wid Starting from the current{UP | DOWN} “string” [“string”] . . . sourceIndex, this command“frame_path” moves up or down in the DOM element index number sequencesearching for a Regular Expression match. IndexSet idx Moves theinternally remembered current index to idx. idx = 0 for the firstelement of the page. idx if you know the specific index you want. Anillegal value is corrected to 0 and a message is issued to the EventLog. IndexMove number Moves forward (positive number) or backward(negative number) the specified number of source index positions,possibly resulting in arriving at the top or bottom of page (but NOTwrapping around). If an IndexMove command attempts to reach beyond theend of the page, or above the beginning of the page, the current indexwill be set to 0 and a Warning will be issued to the Event Log.IndexFollowLink wid “frame_path” Similar to the FollowLink scriptcommand, the IndexElementClick employs the sourceIndex command issues aclick at the current sourceIndex as set by a preceding IndexSet,IndexMove, or IndexFindElement command IndexElementClick wid“frame_path” Similar to the Element Click [NAV] command, this commandissues a click at the current sourceIndex as set by a precedingIndexSet, IndexMove, or IndexFindElement command IndexSubmitClick widframe_path” Similar to SubmitClick command, with same parameters andmeaning. Clicks the button pointed to by the SourceIndex.IndexInputValue wid “type” “extra-1” This is the “Index” version of the“extra-2”, “frame_path” [NAV] InputValue command. Behavior is similar tothe InputValue command, with same parameters and meanings.IndexValidateObjProperty wid Validates that on the current“property-name” “expected-value”, sourceIndex the property named“frame_path” takes on the specified value. If the validation fails thenan ERROR is logged in the EventLog. IndexSaveObjProperty wid “property-On the current sourceIndex in name” “filename”, “frame_path” the page,saves the the named property named to the specified filename. If theproperty does not exist, no action is taken. IndexMouseOver wid x y Atthe current sourceIndex, “frame_path” [NAV] executes a left-buttonMouseOver command. The “x y” values specified are offsets within theobject supplied by the DOM. IndexMouseDown wid [x y] At the currentsourceIndex, “frame_path” [NAV] executes a left-button MouseDowncommand. The optional [x y] values specified are offsets within theobject that are supplied by the DOM. IndexMouseUp wid [x y] At thecurrent sourceIndex, “frame_path” [NAV] executes a left-button MouseUpcommand. The optional [x y] values specified are offsets within theobject that are supplied by the DOM. IndexMouseOut wid x y At thecurrent sourceIndex, “frame_path” [NAV] executes a left-button MouseOutcommand. The “x y” values specified are offsets within the objectsupplied by the DOM.

C. Page Element/Event Stimulation

Once a DOM element is identified, the playback process can take actionson it provided that it is an element that is able to accept actual orsimulated user activity.

1. Representative Implementation

In the representative implementation the page element/event simulationactivity is performed with a command that includes as parameters thenecessary information to identify the action to be taken and thelocation at which it is to be taken. The command syntax belowillustrates how this is accomplished in the representativeimplementation, but alternative implementations will vary in regard tosyntax and semantics but accomplish the same effect.

COMMAND SYNTAX EXPLANATION IndexElementEvent wid “event_name” Thiscommand involves “property_name” “property_value” specifying anevent_name and [“property_name” “property_value”] . . . a sequence of“property_name” “frame_path” [NAV] “property_value” in pairs. Completedetails on how these parameters work in actual practice are given below.

2. Command Explanation

Here is an explanation of how this command works in a practicalrealization.

-   -   1. Command Pairs        -   The [“string” “string”] . . . notation means that you can            have as many pairs as you wish. The following syntax            examples are correct:        -   1. IndexElementEvent wid “event_name” “property_name”            “property_value” “frame_path”        -   2. IndexElementEvent wid “event_name” “property_name”            “property_value” “property_name” “property_value”            “frame_path” NAV        -   3. IndexElementEvent wid “event_name” “property_name”            “property_value” “property_name” “property_value”            “property_name” “property_value” “property_name”            “property_value” “frame_path”

The following syntax examples are invalid:

-   -   1. IndexElementEvent wid “event_name” “frame_path”    -   2. IndexElementEvent wid “event_name” “frame_path” NAV

The example below is valid syntactically, but may produce playbackerrors:

-   -   IndexElementEvent wid “event_name” “property_name” “frame_path”        NAV

This example has five parameters, which follow the form of the firstvalid syntax example above. It is assumed that “frame_path” is aproperty value and “NAV′ as the frame_path.

2. Parameters

The main parameters of this command are the name of the event and thedescriptions of the actions to take. Actions are described in name=valuepairs, of which there can be any number (as indicated by the [ ] . . .notation in the command definition). Here are the specifics:

-   -   a. Event Name:        -   The event_name, which can be taken from the following list,            specifies the kind of event that is to be fired:        -   onabort, onblur, onchange, onclick, ondblclick, onerror,            onfocus, onkeydown, onkeypress, onkeyup, onload,            onmousedown, onmousemove, onmouseout, onmouseover,            onmouseup, onresend, onresize, onselect, onsubmit, onunload        -   Note that there could be other events that could be used            here, depending on how the page is constructed. The above            list is only a suggestion and may not be complete.    -   b. Action Description:        -   The action(s) to be taken are specified in terms of a pair            of parameters: property_name, property_value.        -   These values may only occur in pairs and can be only taken            from the following combinations and options. The values            given below are the exact ones to use; all values shown are            case-sensitive. All other combinations and options,            including empty strings, are ignored without issuance of            Warnings or Errors during playback.        -   1. altKey—sets the state of the ALT key:            -   true—ALT key is not pressed            -   false—ALT key is pressed        -   2. button—sets the mouse button pressed by the user.            Possible values are:            -   0—No button is pressed.            -   1—Left button is pressed.            -   2—Right button is pressed.            -   3—Left and right buttons are both pressed.            -   4—Middle button is pressed.            -   5—Left and middle buttons both are pressed.            -   6—Right and middle buttons are both pressed.            -   7—All three buttons are pressed.        -   3. clientX, clientY—sets the x-coordinate or y-coordinate of            the mouse pointer's position relative to the client area of            the window, excluding window decorations and cross bars. The            value is a long integer expressed in pixels.        -   4. ctrlKey—sets state of the CTRL key. Possible values are:            -   true—CTRL key is not pressed            -   false—CTRL key is pressed.        -   5. ctrlLeft—sets state of the left CTRL key. Possible values            are:            -   true—Left CTRL key is not pressed            -   false—Left CTRL key is pressed.        -   6. offsetX, offsetY—sets the x-coordinate or y-coordinate of            the mouse pointer's position relative to the object firing            the event. The value is a long integer expressed in pixels.        -   7. propertyName—sets the name of the property that changes            on the objects.        -   8. qualifier—sets the name of the data member provided by a            data source object.        -   9. reason—sets the result of the data transfer for a data            source object. Possible values:            -   0—Data transmitted successfully            -   1—Data transfer aborted.            -   2—Data transferred in error.        -   10. repeat—sets whether the onkeydown event is being            repeated. Possible values are:            -   true—event fires two or more times.            -   false—event fires once.        -   11. screenX, screenY—sets the x-coordinate or y-coordinate            of the mouse pointer's position relative to the user's            screen. The value is a long integer expressed in pixels.        -   12. shiftKey—sets the state of the SHIFT key. Possible            values are:            -   true—SHIFT key is not pressed            -   false—SHIFT key is pressed.        -   13. srcUrn—sets the Uniform Resource Name (URN) of the            behavior that fired the event. Possible values are:            -   NULL—default only, cannot be changed.        -   14. This property is set to NULL unless both of the            following conditions are true:            -   A behavior currently is attached to the element on which                the event is fired.            -   The behavior defined in the preceding bullet has                specified a URN identifier and fired the event.        -   15. x, y—sets the x-coordinate, or y-coordinate, in pixels,            of the mouse pointer's position relative to a relatively            positioned parent element. The value is a long integer.        -   16. cancelBubble—set whether the current event should bubble            up the hierarchy of event handlers. Possible values are:            -   “false”: Bubbling is enabled. The next event handler in                the hierarchy will receive the event.            -   “true”: Bubbling is disabled. The next event handler in                the hierarchy will not receive the event.        -   17. keyCode—sets the Unicode key code associated with the            key that caused the event. The property value parameter is a            number. It is 0 if no key caused the event.        -   18. returnValue—sets the return value from the event; valid            property values: “true” and “false”.

D. Page Element Validation

Once pages are downloaded, the need for regression testing requires theability to confirm that particular values are present as required. Suchvalidations steps are also called “checkpoints” or “matchpoints”. Priorart has provided for the ability to confirm text entries on a page asrendered, but in many practical cases the need for validation extendsinto the content of the page itself. The present invention extends thenotion of validation to include any kind of Document Object Model (DOM)property or attribute taking on any pre-specified value. When therequired value is found the corresponding test playback PASSes; when arequired value is not found the corresponding test playback FAILs.

1. Representative Implementation

As the command syntax shows below, in the representative implementationthe user can specify the object to be validated in several differentways, with more or less detail. Three typical formats for this commandare shown, but other variations are possible within the conceptidentified by this action.

DOM Element Value Extraction/Insertion Commands COMMAND SYNTAXEXPLANATION ValidateSelectedObjProperty wid idx Validates the specificcontent of [[“id_name”] “id_value”] name value the described DOM objectin “frame_path” the indicated frame (as [1] ValidateSelectedObjPropertywid specified by the frame_path). idx name value “frame_path” Details ofthe available names [2] ValidateSelectedObjProperty wid are usuallyfound using the idx [“id_value”] name value eValid Page Map facility.“frame_path” If the object found at idx does [3]ValidateSelectedObjProperty wid not have the given name, or if idx[[“id_name”] “id_value”] name wid name is correct and the value value“frame_path” the name currently has is incorrect, or if name is notfound, an ERROR results. If the object with ID equal to id_value existsand the name has the specified value, or if name is correct and thevalue the name currently has is incorrect, or if name is not found, anERROR results. If the object with object id_name equal to id_valueexists and the name has the specified value, or if name is correct andthe value the name currently has is incorrect, or if name is not found,an ERROR results.

E. Page Get/Put Operations

The user may wish to read and/or set the values selected by the searchesgiven above. This is done with special Get/Put commands, illustrated ina typical syntax below.

1. Representative Implementation

Here are typical commands that implement the functional described above,expressed in the standard command format. The command syntax belowillustrates how this is accomplished in the representativeimplementation, but alternative implementations will vary in regard tosyntax and semantics but accomplish the same effect.

DOM Element Value Extraction/Insertion Commands Working AssumptionsAbout These Commands: There is only one elementValue known to eValid atany time. The elementValue is always a string. The initial value of theelementValue is always set to empty. The value of the elementValuepersists between pages, as long as the current playback is running.Commands that use this [internally stored] elementValue value alwaysrefer to the current page. eValid does not modify the elementValueexcept by action of the commands below. COMMAND SYNTAX EXPLANATIONValueSet value Sets the elementValue to the specified value.ValueGetElement wid Gets the value of the named element at name“frame_path” sourceIndex and saves it in elementValue. If the objectfound at sourceIndex does not have the given name, or if name is correctand the value the name currently has is incorrect, or if name is notfound, an ERROR results. ValuePutElement wid name Inserts the currentelementValue into the “frame_path” specific attribute of the describedDOM object in the indicated frame (as specified by the frame_path).ValueSave “filename” Saves the elementValue into the specified [APPEND]filename. If APPEND is present, the value is placed at the end of thenamed file. in the indicated frame (as specified by the frame_path) intothe current elementValue.

F. Page Navigation Header Manipulation

To support a wide range of different browser options one needs to beable to manipulate the “headers”, the pre-request and post-requestinformation at the HTTP/S level. This lets the representativeimplementation imitate other browsers and do other test-relatedmanipulations of how the interaction between the test enabled webbrowser and the server operate.

A characteristic of the implementation of this feature is that the testenabled web browser is that searches are made for objects of specifiedproperties on the current page, the identified location can be movedahead or behind the found object's location, and a variety of user inputactions can then be applied to accurately and reliably reproduce theeffect of human input.

1. Operational Introduction

In some cases it is necessary to modify the HTTP header information,e.g. for monitoring or for special effects. This is done by editing thedata required as an extra argument on a GotoLink command. Headerinformation is contained in a single string. Sets the current value ofthe header with name to value to the specified string for the currentplayback up to the next InitLink or GotoLink command, after which thevalues are reset to “normal/default.”

The values possible in the headers string are those that are used instandard HTTP/S protocol passages. Whether a specific header name isaccepted with effect by a specific server can only be determined byexperimentation.

GotoLink Command Description With Header String Processing COMMANDSYNTAX EXPLANATION GotoLink wid “URL” Goes to the specified URL with“frame_path” the browser, waits for the page [“header_string”] to comeup (if it can within the GotoLinkSubmit wid “URL” required minimumtime), and “frame_path” gives control back to the user. If[“header_string”] the WebSite has frames active then the recordingincludes the frame_path of the frame; on playback this is the frame towhich the browser is pointed with the URL. This action is the same astyping in a URL and pressing RETURN. The header_string, if used, mustseparate multiple HTTP header strings with newline characters, e.g.User-id: identifier\n User- Password: something

2. Suggested Usages

Here is a typical instance of use of this command to apply modifiedheaders:

-   -   GotoLink 0 “www.cnn.com” “” “USER: name \n    -   PASSWORD: pass \n SessionID: 654321”

3. Modifying the User Agent String

One example of the use of this feature is to set the User-Agent name tospoof the current test enabled web browser to appear to be a differentkind or type of browser and thus to force the server to deliver pages asif eValid were that type of browser. Note: There is also an availableSetUserAgent editable command that has some of the same effects. Thetable below specifies some command values for this.

OS Browser Typical User-Agent String Definition Windows IE 5.0Mozilla/4.0 (compatible; MSIE 5.0; 98 Windows 98; I) Windows IE 5.5Mozilla/4.0 (compatible; MSIE 5.5; 98 Windows 98; I) Windows NetscapeMozilla/4.5 [en]C-CCK-MCD 98 4.5 {CADGraphicArts} (Win98; I) Windows AOL6.0 Mozilla/4.0 (compatible; MSIE 5.01; 98 MSN 2.5; Windows 98) WindowsNetscape Mozilla/5.0 (Windows; U; Win98; en-US; 98 6.0 m18)Gecko/20001108 Netscape6/6.0 Windows IE 5.0 Mozilla/4.0 (compatible;MSIE 5.0; NT Windows NT;) Windows IE 5.5 Mozilla/4.0 (compatible; MSIE5.5; NT Windows NT;) Solaris IE 5.0 Mozilla/4.0 (compatible; MSIE 5.0;2.5.1 SunOS 5.5.1 sun4m; X11) Solaris IE 5.0 Mozilla/4.0 (compatible;MSIE 5.0; 2.6 SunOS 5.6 sun4u; X11)

G. DOM-Based Adaptive Playback

The adaptive playback feature keeps tests from failing due toinconsequential changes in the underlying web page. Without adaptiveplayback, tests can be too “brittle” to be practical emulations of humaninput, which easily adapts to slightly changed page conditions.

Previously adaptive playback commands did not take as strong advantageas possible through use of the unique DOM property called ID, which isincreasingly used in modern web page development (the ID property ofeach page element is given a “permanent” name automatically).

This enhanced capability operates in parallel with and in concert withother activities that may be going on inside the browser (based on theuse by the test enabled web browser of standard browser components andthe standard DOM available within such browsers).

H. Programming Language Interface

Here is an explanation of how this command works in the practicalrealization of the invention.

The automatic conversion of a recorded script into a programminglanguage means that, to the user, a test enabled browser can record intoa full programming language.

A characteristic of the implementation of this feature is that theresulting program, which can be expressed in a variety of programminglanguage, e.g. C++ or PERL or C# or Visual Basic, etc., has thecapability of full programmability, thus providing the test script withthe power and flexibility available from the programming language inwhich the playback sequence is embedded.

1. Representative Implementation

Use of the programmatic interface feature will allow a user to convertan actual test enabled browser script into a form that can beincorporated into:

-   -   A PERL execution using a test enabled browser PERL support        library.    -   A C++ program execution using a test enabled browser C++ support        library.    -   A VB, or C#, or other language used to interface into the        support library.

Hence, the script used within the representative implementation iseffectively converted into a sequence of function calls or methodinvocations that are meaningful in the underlying API for the testenabled browser in that language context. Accordingly, a script thatdrives the test enabled web browser can equivalently be implementedoperationally in a free-standing computer program whose execution isidentical to the scrip-driven behavior, and visa versa.

2. Advantages

Playback of scripts is semi-static in that—by design—the scriptinglanguage is simple, generic, agnostic, and is not cluttered withunnecessary programming language details. The result is a scriptingsystem that is a good compromise between expressive power and clarityand ease of use.

However, in some cases the availability of the full power of a procedureoriented language offers the website tester a significant example. Forexample, using test engine function calls from within a programminglanguage would allow for the use of loops, data structures, conditionalexecutions, extraction of values, etc.

3. Operating Mode

Here is how this process works (for C++ or PERL, for illustrationpurposes):

-   -   a. Record and perfect your script.evs with the representative        implementation using the record facility and possibly augmented        with manual edits of the script.    -   b. When the script is deemed ready, invoke the script conversion        option and select the target language/environment.    -   c. Play the script back and observe that the converted script is        now stored in new files named “script.evs.pI” or        “script.evs.cpp.”    -   d. Each generated file is a “fragment” of code that can be        dropped directly into a PERL wrapper or a CPP wrapper.    -   e. The test enabled web browser commands, converted into PERL or        CPP, are “function calls/method calls” into the CPP or PERL        interface library that responds to them identically as if they        commands were run in the test enabled web browser.    -   f. The wrapper program, in CPP or PERL, is free-standing and        contains ALL of the interface logic required to have the test        enabled browser behave according to the instructions in the        sequence of function calls/method invocations.    -   g. If you do nothing else to the script at this point but simply        run the PERL or CPP program then you will have the identically        same effect as running the script in the test enabled web        browser.    -   h. You have the option, if you wish, to add logic, and data        structures, and whatever other kind of programming detail you        want to add in the same programming language.

I. URL Sequence Capture

Playback of a script involves download of several parts of a page whenthe browser navigates to the page. This feature extracts the actual URLsequence (from data which the test enabled browser already has) andpresents it as a working eValid script that can be better used inLoadTest runs.

A characteristic of the implementation of this feature is that the testenabled web browser can emulate the sequence of URL downloads withoutneeding to completely browse and render each page, a characteristic thathas primary application in creation of equivalent protocol loading on aserver, as if the test enabled browser were running independently.

1. Representative Implementation Behavior

The basic idea of this feature is to create, at script playback time, acomplete derived URL trace, in a format ready to be submitted to anassociated utility program that retrieves specified URLs using theHTTP/S protocol. The derived trace shows all of the URLs from thatactual playback but does not represent coherent state-preservingactivity.

2. Overview of Operation

When used in the associated URL retrieval utility, the derived URL tracefile will visit all of the URLs that an actual playback will visit—butwithout any browsing of pages (i.e. no rendering, creation of DOM, etc).Such a URL trace playback will therefore replicate the full sequence ofURLs that are downloaded in browser playback—including intra-commandwait times—but with “reduced fidelity”. The derived URL trace script canbe expected to play back at a faster speed than the full, normal mode,playback because the test enabled browser is doing significantly lesswork.

3. Operational Procedure

The procedure to use this feature in the representative implementationis as follows:

-   -   1. Select the script that you want to process, e.g. script.evs.        -   Turn on the Detailed Timings option and also turn on the            Create URL Trace option.        -   Play back the original script. The conversion process is            accomplished during actual playback to assure the accuracy            of the URL sequence extraction.        -   The resulting derived URL trace script will be saved as            “URL.script.evs”.        -   The URL trace script has the usual headers, has a “Serve            URL” at the front of the script, and has a “Serve FULL” at            the end.        -   Load the derived URL trace script in this form to confirm            the results.        -   An eVlite run of “URL.script.evs” now will mimic the same            sequence of URL downloaded in the original “script.evs”.

4. Example of Script Conversion

Here is an example of the effect of the transformation of a regular testenabled web browser script into a derived URL trace script.

Original Script

######################################################################## # Original Script . . . ResetTimer InitLink“http://www.domain.com/Playback/URL.trace.html” ElapsedTime . . .

Derived Script

######################################################################## # URL trace script derived from script.evs . .. ResetTimer GetURL “http://www.domain.com/Playback/URL.trace.html”GetURL “http://www.domain.com/Parts/newevalid.css” GetURL“http://www.domain.com/Images/ evalid_logo_white_trsp_top_100x52.gif”GetURL “http://www.domain.com/Images/evback.gif” ElapsedTime . . .

J. Page Analysis and Structure Extraction

Detailed DOM scanning yields dynamically created links. The key is thateValid does the scan “over the wire” and “from the client perspective”—asignificant technical advantage.

Access to the DOM for analytic purposes is assured because the testenabled web browser uses standard browser components, among which is aninterface to the DOM for each page that is browsed.

A characteristic of the implementation of this feature is that theresulting spidering of the web page is dependent on how the pageactually exists at the time it is served to the test enabled webbrowser, and does not include or exclude any details or effects that arepertinent to the structure, organization, layout, and content of saidweb page.

1. Dynamic Creation of Internal Work List

More selective inclusion and exclusion of links in the work-to-be-donelist/tree. This is important to a successful and useful scan, being ableto decide based on page properties, mainly the URL but also on otherinternal criteria, whether to add it to the work list. If you do not dothis you would have to scan everything you find, and you may not wantthat. User control is important.

The criteria for inclusion and exclusion are inclusive of any propertyof the page, its component elements, it's DOM properties, and its linksto other pages. All of this information is available because the testenabled web browser uses standard browser components, among which is aninterface to the DOM for each page that is browsed.

A characteristic of the implementation of this is that the origin of thesearch process described above can be determined by the user, so thatthe search can be made of one or more websites or sub-websites, asspecified by a starting or “root” URL and as constrained according tothe claimed limits and constraints, so that data can be collected onfull websites or sub-websites according to the wishes and expectationsof the user.

Within the context of the search, the following criteria can be appliedto include or exclude individual pages based on the following criteria:

-   -   a. The specific character strings used in the URL, which can be        specified as case-sensitive or not;    -   b. Whether or not the page shares the domain with the specified        root domain;    -   c. Whether the domain name is found on a list of permitted        domains;    -   d. An analysis of scripts within the current page;    -   e. Analysis of objects within the current page;    -   f. The protocols (HTTP/S and non-HTTP/S) used to retrieve the        page;    -   g. The type of page extension used:    -   h. The content of query strings that may be associated with the        URL.    -   i. The accumulated depth of dependence chains in the scan:    -   j. The total time consumed in the scan;    -   k. The total number of pages examined;    -   l. The total number of page to page dependency links accumulated        in the scan;    -   m. The total volume of data downloaded in the scan;    -   n. Whether the page was previously visited in the scan;    -   o. The response to a user-supplied program that analyzes the        entire content of the page, as supplied to it by the invention        in the same pure-HTML form it was used for internal automated        analysis.

2. Detailed Page Analysis for Properties

Detailed analysis of DOM properties immediately follows from #1 above.The idea is, the text enabled browser can see in the pages in completedetail, extract anything, and use that in website comparison activities.

The analysis of properties is assured because of the architecture of thetest enabled web browser. All of this information is available becausethe test enabled web browser uses standard browser components, amongwhich is an interface to the DOM for each page that is browsed.

A characteristic of the implementation of this feature is that that theinformation that is collected and stored in a database is availableusing standard browsing components and standard DOM models, such as aretypically employed in available general purpose web browsers of severalkinds and types.

3. Dependency Lists Generated Internally

Page to page dependency capture based on the dynamic links within thecurrent page follows from #1 above. The page to page dependency tree canbe kept internally in a linked list of parent-child dependencies. Thehis claim also incorporates the notion of a subwebsite, being thosepages at/below an established root.

A characteristic of the implementation of this feature is that theinterface between the analysis function and the database function is onethat uses standard database interface components, such that alternativedatabase systems can be used to contain the information that is capturedwithout any loss of information or content.

The various aspects, features, embodiments or implementations of theinvention described above can be used alone or in various combinations.

The invention can be implemented by software, hardware, or a combinationof hardware and software. The invention can also be embodied as computerreadable code on a computer readable medium. The computer readablemedium is any data storage device that can store data which canthereafter be read by a computer system. Examples of the computerreadable medium generally include read-only memory and random-accessmemory. More specific examples of computer readable medium include Flashmemory, EEPROM memory, memory card, CD-ROM, DVD, hard drive, magnetictape, and optical data storage device. The computer readable medium canalso be distributed over network-coupled computer systems so that thecomputer readable code is stored and executed in a distributed fashion.

The many features and advantages of the present invention are apparentfrom the written description. Further, since numerous modifications andchanges will readily occur to those skilled in the art, the inventionshould not be limited to the exact construction and operation asillustrated and described. Hence, all suitable modifications andequivalents may be resorted to as falling within the scope of theinvention.

What is claimed is:
 1. A non-transitory computer readable mediumincluding at least computer program code executable by a clientcomputer, said computer readable medium comprising: computer programcode, executable by the client computer, for creating a playback programthat senses document object model (DOM) events, the playback programincluding computer programming commands that support parameters;computer program code, executable by the client computer, for providinga test-enabled browser capable of performing the playback program,wherein when the test-enabled browser performs the playback program, thetest-enabled browser is controlled to implement testing specified by theplayback program, wherein the test-enabled browser accesses scriptingcapabilities of the test-enabled browser to perform testing specified bythe computer programming commands of the playback program, wherein thetesting being performed is testing a web-based resource, the web-basedresource having a DOM representation with a plurality of DOM elements;and computer program code, executable by the client computer, forproviding a browser programming interface that enables the test-enabledbrowser to have direct access to the DOM representation, wherein atleast one of the computer programming commands operates to sense a DOMevent, and wherein the at least one of the computer programming commandsor at least another of the computer programming commands operates tocause one or more actions to be performed in response to the sensing ofthe DOM event, and wherein at least one of the actions operates, via thebrowser programming interface, to input a value or content into at leastone of the DOM elements within the DOM representation of the web-basedresource being tested.
 2. A non-transitory computer readable mediumincluding at least computer program code, said computer readable mediumcomprising: computer program code for providing a test-enabled browsercapable of performing a playback program, wherein when the test-enabledbrowser performed the playback program, the test-enabled browser iscontrolled to implement testing specified by the playback program,wherein the testing being implemented is testing a web-based resource,the web-based resource having a document object model (DOM)representation with a plurality of DOM elements; and computer programcode, executable by the client computer, for providing a browserprogramming interface that enables the test-enabled browser to havedirect access to the DOM representation, wherein the playback program isexpressed using a sequence of computer programming commands that supportparameters, and wherein one or more of the computer programming commandsprogrammatically senses document object model (DOM) events associatedwith the test-enabled browser, wherein the one or more computerprogramming commands programmatically causes one or more actions to beperformed in response to the sensing of the DOM events, and wherein atleast one of the one or more actions operates, via the browserprogramming interface, to input a value or content into at least one ofthe DOM elements within the DOM representation of the web-based resourcebeing tested, and wherein the test-enabled browser accesses scriptingcapabilities of the test-enabled browser to perform testing specified bythe computer programming commands of the playback program.